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Using the MARS Model in non-ATM NBMA Networks 


Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 


Copyright (C) The Internet Society (1998). All Rights Reserved. 


Abstract 


Initially developed for IP over ATM, the RFC 2022 (MARS) model is 
also applicable to other NBMA networks that provide the equivalent of 
switched, point to multipoint connections. This short document is 
intended to state the obvious equivalences, and explain the less 
obvious implications. No changes to the MARS model per se are 
suggested or required. RFC 2022 is not required over NBMA networks 
that offer Ethernet-like group addressing functionality. 


1. Introduction 


Most network layer models, like the one described in STD 5, RFC 1112 

[1] for IP multicasting, assume sources may send their packets to an 

abstract ’multicast group addresses’. Link layer support for such an 
abstraction is assumed to exist, and is provided by technologies such 
as Ethernet. 


Some NBMA networks (e.g. ATM using UNI3.0 or UNI3.1 signaling [4,5]) 
do not support a multicast (or group) address abstraction. In these 
environments multicasting is typically supported through point to 
multipoint calls (or emulated with multiple point to point calls). 
The MARS model (RFC 2022) [2] was originally developed by the IP over 
ATM working group, and so uses ATM-centric descriptive language. For 
completeness this memo explains how RFC 2022 can be applied to other 
NBMA technologies. 
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2. RFC 2022's basic assumptions. 


Section 3 of [2] describes the basic assumptions that the MARS model 
makes about the services available from the link layer network (using 
ATM as the specific case). In summary these are: 


The ATM model broadly describes an ’AAL User’ as any entity that 
establishes and manages VCs and underlying AAL services to 
exchange data. An IP over ATM interface is a form of ’AAL User’ 


The most fundamental limitations of UNI 3.0/3.1’s multicast 
support are: 


Only point to multipoint, unidirectional VCs may be 
established. 


Only the root (source) node of a given VC may add or remove 
leaf nodes. 


Leaf nodes are identified by their unicast ATM addresses. 


Given this point to multipoint call service, the MARS document goes 
on to describe two architectures for emulating multipoint to 
multipoint IP multicasting - the VC Mesh, and the Multicast Server. 
In either case it was assumed that IP/ATM interfaces (whether in 
routers or hosts) are allowed to originate and manage outgoing point 
to multipoint calls without network operator intervention or manual 
provisioning. 


The MARS document also specifies that AAL5 be used for all SVCs, 
implying a requirement that the underlying link service supports the 


atomic exchange of PDUs. 


3. Generalising the MARS model. 


Any NBMA service that offers an equivalent to (or superset of) the 
ATM point to multipoint call service can use the MARS model directly. 
It must be possible to transmit atomic data units bi-directionally 
with point to point calls, and unidirectionally (from root to leaves) 
on point to multipoint calls. 

A MARS is an entity known by its NBMA address. 

A MARS Client is an entity known by its NBMA address. 


An MCS (where needed) is an entity known by its NBMA address. 
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The MARS control messages defined in sections 4 onwards of the MARS 
document are shown carrying ATM addresses. Using different marSafn 
(Address Family) values in the fixed header of MARS control messages 
allows MARS entities to indicate they are carrying other types of 
NBMA addresses (as done in NHRP [3]). As for NHRP, the 
interpretation of the ’sub-address’ fields shall be in the context of 
the address family selected (which means it will often simply be 


null). 
In all cases where {IP, ATM.1, ATM.2, ...} mappings are referred to, 
they may be interpreted as {IP, NBMA.1, NBMA.2, ...} in the context 


of whatever NBMA network you are deploying MARS. 
The MARS Cluster is defined in [2] as: 


The set of ATM interfaces chosing to participate in direct ATM 
connections to achieve multicasting of AAL_SDUs between 
themselves. 


It is trivial to observe that the cluster definition is independent 
of the underlying link layer technology. A revised definition 
becomes: 


The set of NBMA interfaces chosing to participate in direct NBMA 
connections to achieve multicasting of packets between themselves. 


The term ’Cluster Member’ continues to refer to an endpoint that is 
currently using a specific MARS for multicast support. The potential 
scope of a cluster may be the entire membership of a LIS, while the 
actual scope of a cluster depends on which LIS members are actually 
registered with the cluster’s MARS at any given time. 


Section 3.4 of [2] provided a set of mneumonics for the signalling 
functions available to AAL Users. These mneumonics are then used in 
the remainder of [2] to indicate link layer events to which MARS 
entities might react. Recast from the perspective of an NBMA based 
MARS entity, the descriptions would now read: 


The following generic signalling functions are presumed to be 
available to local MARS entities: 


L_CALL_RQ Establish a pt-pt call to a specific endpoint. 

L_MULTI_RO Establish pt-mpt call to a specific endpoint. 

L_MULTI_ADD Add new leaf node to previously established pt-mpt 
call. 

L_MULTI_DROP Remove specific leaf node from established pt-mpt 
call. 

L_RELEASE Release pt-pt call, or all Leaves of a pt-mpt call. 
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The signalling exchanges and local information passed between MARS 
entity and NBMA signalling entity with these functions are outside 
the scope of this document. 


The following indications are assumed to be available to MARS 
entities, generated by by the local NBMA signalling entity: 


L_ACK Succesful completion of a local request. 
L_REMOTE_CALL A new call has been established to the MARS 
entity. 


ERR_L_ROFAILED A remote NBMA endpoint rejected an L_CALL_RQ, 
L_MULTI_RQ, or L_MULTI_ADD. 

ERR_L_DROP A remote NBMA endpoint dropped off an existing 
call. 

ERR_L_ RELEASE An existing call was terminated. 


The signalling exchanges and local information passed between MARS 
entity and NBMA signalling entity with these functions are outside 
the scope of this document. 


4. Open Issues. 


The trade offs between VC Mesh and Multicast Server modes may look 
quite different for each NBMA technology. This will be especially 
true in the area of VC (or equivalent) resource consumption in the 
NICs of hosts, routers, and endpoints supporting MARSs or MCSs. The 
use of VC mesh mode is most vulnerable to NBMA technologies that are 
Signalling intensive or resource challenged. 


Sizing of Clusters (and hence LISes) will also be affected by a given 
NBMA network’s ability to support lots of pt-mpt calls. 

Additionally, you cannot have more members in a cluster than you can 
have leaf nodes on a pt-mpt call, without hacking the MARS model [6]. 


On going developments in server synchronisation protocols for 
distributed RFC 2022 implementations are expected to be applicable to 
non-ATM NBMA networks. 


Quality of service considerations are outside the scope of this 
document. They will be very specific to each NBMA technology’s 
capabilities. Related work is being pursued outside the ION Working 
Group. 


If the NBMA network offers some sort of native multipoint to 


multipoint service then use of the MARS model may not be optimal. 
Such situations require further analysis. 
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Security Considerations 


This memo is informational, and specifies no protocol for deployment. 
No specific non-ATM NBMA network technologies or security 
characteristics are discussed. Should enhancements to security be 
required, they shall be added as an extension to the base 
architecture in RFC 2022, or described in documents explicitly 
proposing use of RFC 2022 over specific NBMA technologies. 
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Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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